Amiga Plus 1995 #2/Amiga Plus CD - 1995 - No. 2.iso/internet/faq/englisch/osf-computingenvironment

Text File | 1995-04-11 | 48.4 KB | 1,026 lines

Posted-By: auto-faq 3.1.1.2
Archive-name: dce/faq
Revision: 1.6 1995/02/18 03:00:59
Posting-frequency: monthly



  This document answers some Frequently Asked Questions concerning
  the OSF Distributed Computing Environment.
  It is posted monthly to comp.soft-sys.dce, as well as
  comp.answers, and news.answers.

  The document is maintained by Jon Mauney, [e-mail]
  Suggestions, corrections, and updates are actively sought.

  This FAQ is available by anonymous ftp from
        ftp.dstc.edu.au in /pub/DCE/FAQ
  and is available for browsing at the OSF's WWW server.
        http://www.osf.org:8001/dce/faq-mauney.html

  Last modified on Feb 14, 1995

Questions answered in this document:

Q 1: What is DCE?
Q 2: What are the advantages of DCE?
Q 3: Where can I get online information about DCE?
Q 4: What books are published on DCE?
Q 5: What about books on DME?
Q 6: What platforms support DCE?
Q 7: What products use DCE?
Q 8: Several of the other questions concern "interfaces".
      What is meant by an interface in DCE RPC?
Q 9: Can a DCE client import multiple interfaces?
Q 10: Can a DCE client connect to multiple servers?
Q 11: Can a DCE server export multiple interfaces?
Q 12: Can a process be both a server and a client?
Q 13: How do I perform asynchronous RPC?
Q 14: How can a server keep track of multiple clients?
Q 15: How can a server detect that a client as exited or crashed?
Q 16: Will Windows NT communicate with DCE?
Q 17: How efficient is DCE RPC?
Q 18: What is the practical limit on the size of a DCE cell?
Q 19: How much memory and disk space is required for DCE services?
Q 20: Where can I find an ACL manager to include in my application?
Q 21: Is DCE an official standard?
Q 22: The DCE threads uses draft 4 of the standard, but
  Posix threads standard has moved beyond draft 4.
  Will DCE change to the most recent standard?
Q 23: Is anyone using DCE for real-life mission-critical systems?
Q 24: Is it possible for a machine to be a member of more than one DCE cell?
Q 25: Is it possible for a user in one cell to use secure services
  in another cell?
Q 26: What is the relationship between DCE and CORBA?
Q 27: Is DCE IDL the same as all the other IDL's in the world?
Q 28: Can I move idl-compiled stubs from one platform to another and rebuild
      the object files locally?
Q 29: Does DCE Security interoperate with other Kerberos systems?
Q 30: Can I use DCE from C++?
Q 31: Can I write an application that uses DCE and X11/Motif?
Q 32: Where can I get more information about DCE and DCE-related products?
Q 33: What are DCE RFCs, and how can I get them?
Q 34: Where can I get the Public Domain version of DCE?
Q 35: Is there a DCE Users Group I can join?

==================================================================

Q 1: What is DCE?

   DCE is the Distributed Computing Environment, from the
   Open Software Foundation. (It is called "the DCE" by sticklers
   for grammatical consistency.)

   DCE consists of multiple components which have been integrated
   to work closely together.  They are the Remote Procedure Call
   (RPC), the Cell and Global Directory Services (CDS and GDS), the
   Security Service, DCE Threads, Distributed Time Service
   (DTS),and Distributed File Service (DFS).  The Threads, RPC, CDS,
   Security, and DTS components are commonly referred to as the
   "secure core" and are the required components of any DCE installation.
   DFS is an optional component.  DCE also includes administration tools
   to manage these components.

   DCE is called "middleware" or "enabling technology."  It is not
   intended to exist alone, but instead should be bundled into a
   vendor's operating system offering, or integrated in by a third-party
   vendor.  DCE's security and distributed filesystem, for example,
   can completely replace their current, non-network, analogs.
   DCE is not an application in itself, but is used to build custom
   applications or to support purchased applications.

==================================================================
Q 2: What are the advantages of DCE?

   First, DCE provides services that can be found in other computer
   networking environments, but packages them so as to make them
   much easier to use.  For example, the DCE Remote Procedure Call
   (RPC) facility provides a way of communicating between software
   modules running on different systems that is much simpler to code
   than older methods, such as using socket calls.

   Second, DCE provides new capabilities that go beyond what was
   available previously. The DCE Security Service provides a
   reliable way of determining if a user of a distributed system
   should be allowed to perform a certain action, for example.  This
   is very useful for most distributed applications, yet the design
   and implementation effort entailed in providing such a capability
   would be prohibitive for an individual developer.

   Third, DCE integrates components in a manner that makes them more
   valuable together than separately.  For example, the DCE RPC uses
   threads in such a way that a developer can implement a
   multi-threaded server without ever explicitly creating or
   destroying a thread.

   Finally, DCE supports both portability and interoperability by
   providing the developer with capabilities that hide differences
   among the various hardware, software and networking elements an
   application will deal with in a large network.  For example, the
   RPC automatically converts data from the format used by one
   computer to that used by another.

   Portability is a measure of the ease with which a piece of
   software that executes on one type of computer can be made to
   execute on a different type of computer. Interoperability is a
   measure of the ability of computers of different types to
   participate in the same distributed system.

==================================================================
Q 3: Where can I get online information about DCE

  First of all, the official documentation for DCE is not available
  for anonymous ftp. But there are several sites providing
  lots of other information.  Here are some of the most useful:

  The Open Software Foundation maintains a WWW server with information
  about all the OSF products, including DCE.
        http://www.osf.org:8001/dce/index.html
  takes you directly to the DCE index.
  Highlights of the OSF's web server include a complete list of DCE
  products, the DCE Request for Comments documents (RFCs), and a
  hypertext version of the Frequently Asked Questions list.

  Project Pilgrim at the University of Massachussetts has a DCE homepage at
        http://info.pilgrim.umass.edu/pub/osf_dce/osf.html
  Their server provides a complete set of RFCS, searchable by http
  and also by gopher, at
        gopher://info.pilgrim.umass.edu/77/lib/.wais-sources/osf-dce-rfc.txt
  and a directory of contributed software, currently consisting of
  performance measurement utilities from Pilgrim, and book examples from
  O'Reilly&Associates.

  The Center for Information Technology Integration at the
  University of Michigan has several pieces of DCE information
  on their servers. The big attraction here is the set of
  CITI Technical Reports related to DCE, in gopher-searchable format.
  You can get to the tech-reports from the CITI homepage,
        http://www.citi.umich.edu
  or go directly to the gopher directory:
        gopher://citi.umich.edu/00/public/techreports
  CITI also offers the MVS DCE Users Group homepage
  (which is still under development). Included here
  are a set of IBM whitepapers on the subject, in postscript form.
        http://dcewww.citi.umich.edu:8080/mvsdce

  Transarc has some hints and examples available for anonymous ftp.
        ftp://grand.central.org:/pub/devkit/doc
  These are informal, practical discussions of how to handle real-world
  problems such as changing the IP address of the CDS server,
  implementing peer-to-peer RPC, handling key management, etc.

  Many of the local DCE users groups maintain WWW pages:
    Massachusetts DCE Users Group
        http://dceusers.bc.edu/dceusers/dceusers.html
    New York DCE Users Group
        http://www.osf.org:8001/dce/user-groups/ny/
    Arizona DCE Users Group
        http://www.adug.org/

==================================================================
Q 4: What books are published on DCE?

  Documentation on DCE should be suppiled with vendor products.  The
  OSF sells complete sets of documentation. The DCE set consists of
  14 volumes and costs $525.  Documentation for version 1.1 is
  available.
  The three volumes of specifications (AES) can be purchased separately
  for $100 (plus shipping).

    Order documentation in the US by contacting:
    OSF Direct Channels
    Phone: [phone]

    Order documentation in Europe by contacting:
    Christine Mambourg, Brussels OSF.
    Phone: [phone], fax: [phone]
    Email: <[e-mail]>

    Order documentation in the Pacific Region by contacting:
    Haruyo Nogami, Tokyo OSF.
    Phone [phone]; fax: [phone]
    Email: <[e-mail]>


  The OSF documentation is also published by Prentice-Hall.  These
  books contain about the same material as the OSF manuals, but are edited
  to improve the presentation.  The Prentice-Hall books generally
  reflect DCE 1.0.1, except for the Administration Guide which reflects
  1.0.2.  The next Prentice Hall edition is slated to reflect DCE 1.1.

        Introduction to DCE                     ISBN 0-13-490624-1
        DCE Administration Reference            ISBN 0-13-643818-0
        DCE User's Guide and Reference          ISBN 0-13-643842-3
        DCE Application Development Guide       ISBN 0-13-643826-1
        DCE Application Development Reference   ISBN 0-13-643834-2
        DCE Administration Guide
          Vol. 1, Introduction                  ISBN 0-13-176546-9
          Vol. 2, Core Components               ISBN 0-13-176553-1
          Vol. 3, Extended Services             ISBN 0-13-176561-2
        Application Environment Specification/Distributed Computing
          RPC Volume                            ISBN 0-13-043688-7
  Other books on DCE:
     Understanding DCE, by Rosenberry, Kenney, and Fisher
          O'Reilly, ISBN 1-56592-005-8
     Guide to writing DCE Appplications,2nd edition
          by Shirley,  Hu, and Magid
          O'Reilly, ISBN 1-56592-045-7
     Distributing Applications Across DCE and Windows NT,
           by Rosenberry and Teague
           O'Reilly, ISBN 1-56592-047-3
     OSF DCE: Guide to Developing Distributed Applications,
          by H. W. Lockhart, Jr,
          McGraw-Hill, ISBN 0-07-911481-4
     DCE--The OSF Distributed Computing Environment, Client/Server Model
       and Beyond; Proceedings of the International Workshop on DCE, 1993
       Lecture Notes in Computer Science #731, Springer-Verlag,
       ISBN 3-540-57306-2
  And for you German-speaking DCE-ers:
  DCE--Das OSF Distributed Computing Environment, Einfuerhrung und Grundlagen,
        by Alexander Schill, Springer-Verlag, ISBN 3-540-55335-5

==================================================================
Q 5: What about books on DME?

  The Distributed Management Environment (DME) is really a separate
  topic from DCE.  But since you asked...

  The DME Distributed Services Component documentation set is available
  from OSF, it costs $100/set Plus $20 for shipping.  This set consists of

        Introduction to DME
        System Administrator's Guide and Reference
        Application Developer's Guide and Reference

  For further information or to order DME docs, contact OSF.
  (See Q4 above for address.)

==================================================================
Q 6: What platforms support DCE?

  DCE is supported on most Unix platforms and many non-Unix platforms.
  Most vendors support at least the "secure core" which means all of the
  DCE services except the Distributed File Service and X.500 interface
  to the Global Directory Service.

  Some products are client-only, which means that the actual servers
  for the DCE services are not provided: Directory Service, Security
  Service, Time Service. Client machines can use these services,
  they simply cannot run the server programs;  another machine
  in the cell must run the server programs.  Application programs
  can be built and run the application servers on these "client-only"
  systems.

  This table summarizes the DCE implementations currently available:
   (This information changes frequently; check with the OSF or
   specific vendors for the latest details. Updates to this list
   are solicited)

   -------------------------------------------------------------
   Platform                     Comments
   -------------------------------------------------------------
Unix platforms:
   DEC-OSF/1 on Alpha AXP:      Secure core and DFS
   Ultrix                       "Starter kit"
   HP-UX:                       Secure Core and DFS
   DG/UX                        Secure Core and X.500
   AIX:                         Secure core and DFS
   SunOS,                       Secure Core, X.500
   Solaris:                     Secure core and DFS
                                Implementation by Transarc, also re-sold by Sun
   Irix                         Secure Core
   SCO                          Secure Core was expected by August 1994
   AT&T GIS, SVR4 on Intel      Secure Core
   Sinix (Mips and Intel)       Secure Core, DFS, and X.500
   Stratus XA/R                 Secure Core developers kit
   Cray Unicos                  Secure Core Client, and DFS server
   System V on Intel            Secure Core, available from Gradient Technology
   Pyramid DC/OSx (SVR4)        Secure Core
   Hitachi HI-OSF/1-MJ (osf/1)  Secure Core, with Japanese on-line doc
   Hitachi HI-UX/WE2            Secure Core
   Sony NEWS (SVR4)             Secure Core
   Fujitsu DS/90 (SVR4)         Secure Core
   Unixware            Secure Core, from Gradient
   Sequent
Non-Unix platforms:
   OpenVms (Vax, and Alpha AXP) Secure core
   Microsoft Windows:           Client-only, available from Gradient Technology
                                Client-only, available from Siemens-Nixdorf
                                Unimetrics has announced DFS client products
                                for Windows
   Macintosh                    Apple has promised support, but
                                details have not been announced
   Windows NT:                  out-of-the-box, NT contains a
                                subset of DCE RPC.
                                        See Q16 below for further discussion.
                                Digital Equipment Corporation has
                                  a DCE client available today, and has
                                  announced intent to support full DCE
                Gradient has a secure core in Early Release
   OS/2:                        Secure core
   HP 3000 with MPE/iX          Limited availability, general availability
                                projected for mid '95
   VM                           Kapsch AG has a client-only secure core
                                product for IBM's VM
   VM/ESA                       IBM has announced intent to support
                                "selected components" of DCE on VM/ESA
   MVS                          client only
   IBM AS/400                   client only
   BS2000                       Client Only
   Bull DPX/20                  Secure Core, X.500, DFS
   GCOS on Bull DPS 9xxx/7xxx   threadless client only

==================================================================
Q 7: What products use DCE?

   The OSF has a living document called DCE Product Listing.  It contains
   information pertaining to products and services related to DCE
   technology.  To receive a copy or to add a product or service to the
   listing contact:
      DCE Product Listing
      c/o Open Software Foundation
      11 Cambridge Center
      Cambridge, MA  02142
      Fax - +1.617.225.2782
      [e-mail]

==================================================================
Q 8: Several of the other questions concern "interfaces".
      What is meant by an interface in DCE RPC?

   An interface is a set of remote procedure call operations and
   associated data.  Every interface contains one or more
   operations.  An operation is an actual remote procedure.  Each
   operation may have input and output parameters associated with
   it, just like any procedure call.

==================================================================
Q 9: Can a DCE client import multiple interfaces?

   Yes. A client can use as many different services as it needs.

==================================================================
Q 10: Can a DCE client connect to multiple servers?

   Yes. A client can connect to multiple servers providing different
   services, and/or multiple servers providing the same service.

   To use multiple servers with the same interface, the client must
   obtain a binding handle for each server and use explicit handles
   in the RPC.

==================================================================
Q 11: Can a DCE server export multiple interfaces?

   Yes. A server can provide service on multiple interfaces
   simultaneously.  A common example is a server which exports an
   application interface and a management interface.

==================================================================
Q 12: Can a process be both a server and a client?

   Yes.  There are two scenarios.
        1) A program might act as a server for interface A,
          and also as a client for interface B.  This is easy.
          The program merely imports interface B like a normal
          client and exports interface A like a normal server.
        2) A program might want to provide a service, and also
          act as a client to other servers that provide the same
          service.  In this case, the programmer must expend more
          effort.  The problem is that the names of the server-side
          functions (manager routines) clash with the names of the
          client stubs.  The solution is to manually build an
          endpoint vector for the server, and use different names
          for the manager routines. For  details on using endpoint
          vectors, see the Lockhart book (Q4 above).
    Note that most server programs also act as clients, since they
    usually access the endpoint mapper (rpcd), and the security
    service;  these actions use RPCs, though it may not
    be obvious in the code.

==================================================================
Q 13: How do I perform asynchronous RPC?

   DCE-RPC is synchronous. The way to make an asynchronous call is
   to create a thread for each RPC call.  You should be able to have
   dozens, if not hundreds, of threads with no problem.

==================================================================
Q 14: How can a server keep track of multiple clients?
      For example, to know what information has already been
      provided to a client, and thus vary subsequent responses.

   The DCE RPC mechanism includes a "context handle" which can be
   created by a server and returned to a client.  The handle is used
   on subsequent RPCs to identify the client.

==================================================================
Q 15: How can a server detect that a client has exited or crashed?

   The context handle provides this ability.  When a context handle
   is created and passed to the client, the DCE runtime library
   keeps track of the connection between client and server;
   this may be done in the network code as in the case of TCP,
   or by DCE-specific ping messages if a connectionless protocol is used.
   When the client dies, the server is notified and executes a "rundown"
   function to clean up its data structures.

==================================================================
Q 16: Will Windows NT communicate with DCE?

   Windows NT comes with an RPC which interoperates with DCE RPC.
   However, it does not use the DCE API (exactly), nor does it support
   many DCE features, such as directory service, security and threads.
   See the book "Distributing Applications Across DCE and Windows NT"
   for more details (see Q4 above).

   The good news is that DEC has committed to delivering a complete
   DCE port running on Windows NT.  It has a DCE client product available
   now, for both Intel and Alpha architectures.

   Information on Digital's DCE on NT product is available at
          http://www.digital.com/info/Customer-Update/940412019.txt.html


==================================================================
Q 17: How efficient is DCE RPC?

  Performance testing at several user organizations has shown that
  DCE RPC performance is similiar to other RPC implementations when
  doing the same things.  The throughput and response times for a
  series of remote procedure calls is similiar.

  The use of features in DCE not present in other implementations
  may consume additional time and resources.  For example,
  name-based binding may required additional time, depending on the
  number of directories traversed.  Using the packet integrity and
  packet privacy features of the security service can increase
  processing times as a linear function of message sizes.

  There are three papers providing preliminary performance data
  published in:
     DCE--The OSF Distributed Computing Environment,
     Lecture Notes in Computer Science #731, Springer-Verlag,
     (see Q4 above for ISBN)


==================================================================
Q 18: What is the practical limit on the size of a DCE cell?

  Good question.  It is still a bit early to have good practical
  experience with large-scale DCE installations.  But there are
  some large-ish cells in operation.

  Certainly it is reasonable to plan on cells with thousands of
  nodes and perhaps tens of thousands of users.

  The University of Michigan Center for Information Technology
  Integration has done a study in which they added 50,000 entries
  to the Cell Directory and to the security registry.  Their results
  are reported in technical reports 93-12 and 94-1.  See Q 3 for
  the ftp site for CITI tech reports.

==================================================================
Q 19: How much memory and disk space is required for DCE services?

  This depends on the size of the cell, the number of users,
  number of services, etc.

  According to a paper present by Dan Hamel of Transarc, at the
  Decorum conference in February 1994, the following can be used
  as rough guidelines:
    Security server: 2k per principal/account
                     same at replicated sites
    Directory server: 10k per directory, 1k per object
                      same at replicated sites
    end-user machines: Each dce_login creates new credential files,
                      which can build up.  Space usage can range
                      from less than 1k to over 100k.

==================================================================
Q 20: Where can I find an ACL manager to include in my application?

    Atrium Technologies has a product called
    DACM (Distributed Access Control Manager).

    HP's OODCE (DCE C++ class library) provides you with a default,
    built-in ACL Manager with the server class.

    Transarc's Encina (transaction monitor) product includes
    an ACL manager.

    Lockhart's book contains a sample ACL manager. (see Q4 above)

    DCE version 1.1 will include a full ACL manager library.

==================================================================
Q 21: Is DCE an official standard?

   OSF calls the specification an Application Environment Specification,
   or AES. The  AES documents both the software programming interfaces and
   also the communications protocols employed by DCE.  Thus it would be
   possible, in theory, for someone to build a compatible
   implementation without using the code from OSF.
   The AES for RPC, Time, and  Directory services have been accepted as
   standards by by X/Open.  The AES for Security is currently undergoing
   review.

   DCE Threads follow the Posix Threads draft standard 1003.4a draft
   4.  DCE Access Control Lists (ACLs) are based on POSIX.6 Draft
   12.  The Distributed Time Service (DTS) uses time formats defined
   by international standards and in POSIX.4.  The Global Directory
   Service (GDS) complies with the X.500 international standard.
   (Although DCE complies with the 1988 version of X.500, not
   the 1992 version.)

   ISO is considering an RPC standard based on the X/Open document.

   DCE's status as a de facto standard is even stronger.  Almost
   every major hardware and software vendor has committed to
   providing DCE on its platform.  These vendors include not only
   OSF stalwarts such as IBM, DEC and HP, but also other key vendors
   such as Novell, Inc.  See Q 6 for a list of DCE vendors.  In addition,
   a number of major user organizations (e.g., the European Economic
   Community) have already embraced DCE as their standard for
   distributed applications.

==================================================================
Q 22: The DCE threads uses draft 4 of the standard, but
  Posix threads standard has moved beyond draft 4.
  Will DCE change to the most recent standard?

   It is hard to predict exactly what will happen.
   But OSF prefers to follow standards rather then invent them.
   Once the threads document is approved as a standard, it would be
   obvious for the DCE to migrate to it.

==================================================================
Q 23: Is anyone using DCE for real-life mission-critical systems?

   Yes, and more every day.  Tokio Marine and Fire Insurance,
   Co., Lehman Brothers, and Charles Schwab have all publically
   described their ongoing rollout of DCE based applications.

==================================================================
Q 24: Is it possible for a machine to be a member of more than one DCE cell?

   No.  A machine can only be in a single cell. However, it is
   possible for cells to cooperate.  See the next question.

==================================================================
Q 25: Is it possible for a user in one cell to use secure services
  in another cell?

  Yes.  The Access Control List (ACL) contains three entry types:
  foreign_user, foreign_group and foreign_other which specify the
  permissions available to users on other cells.  All that is
  required for intercell access, other than physical connectivity,
  is for the two cell's security services to be configured to know
  about each other.
  There is a command, the rgy_edit "cell" command, that must be run, once,
  by the cell admin of the two cells that wish to communicate.  After
  that, it's all transparent.

==================================================================
Q 26: What is the relationship between DCE and CORBA?

  The short answer:
       DCE provides a lower-level programming model than does CORBA.
       DCE is not fully "Object-Oriented".  DCE has far better
       inter-operability than CORBA.  DCE is used as the base
       communications mechanism in some CORBA-compliant products.
       DCE is an optional interoperability mechanism in the
       CORBA 2.0 specification.

  The Long Answer:

    In order to understand the relationship between DCE and the Common
    Object Request Broker Architecture (CORBA) of the Object Management
    Group (OMG), it is necessary to consider the past, the present and the
    future.

    Past - Historically, the object paradigm has been viewed as a break
    with procedural styles of the past.  Objects, which encapsulate data
    and procedures behind an external interface, are often contrasted with
    other approaches where procedures and data are treated separately.

    In this context, DCE is a descendant of the procedural school which
    emphasizes the decomposition of programs into procedures and achieves
    distribution by locating some of those procedures remotely.  Thus
    there was a tendency for the object community, including the OMG, to
    view DCE as technology which was obsolete before it was available.

    However this view ignored the fact that designers of distributed
    systems had for a long time recognized that the most successful
    approach to developing distributed systems was to create encapsulated
    objects that can only be accessed via well defined interfaces.  Thus
    the cornerstone of DCE RPC is the interface definition language (IDL)
    which allows the external attributes of a set of server operations to
    be specified.

    Furthermore, the name-based binding mechanisms of DCE were extended to
    include the ability to bind to a server based on the object instances
    which it supports.  These object binding mechanisms also allow the
    transparent selection among multiple implementations of the same
    server operations based on the type of the specified object.  In
    object terminology this is called polymorphism.

    The DCE notion of a server supporting interfaces consisting of one or
    more operations is so close to the notion of an object which provides
    one or more methods, that it should be no surprise that CORBA 1.1
    defies an IDL which differs from DCE IDL in only a few significant
    respects.

    Principal among these is that in CORBA IDL every call must specify an
    object, which is used in determining the server to use.  DCE can do
    this as well, but there is more work involved and it is optional.
    Another difference is that CORBA IDL allows an interface to be defined
    as a extension of one or more other interfaces, this is called
    interface inheritance.

    The use of object oriented techniques and principles should not be
    confused with using an object oriented language.  Object oriented
    designs can be expressed in procedural languages, and in fact most of
    the current object environments supported C before supporting C++ or
    Smalltalk.  Therefore, the fact that the DCE API is implemented in C
    is no barrier to using it to create a distributed object system.  In
    fact, CORBA 1.1 does specify C language bindings.

    Present - CORBA 1.1 defines only the interface between application
    components and the object request broker implementation provided by a
    vendor.  Clearly it is intended that objects which interact with the
    environment provided by a given vendor will be able to interoperate
    across the systems and networks supported by that vendor.  However,
    CORBA 1.1 does not specify how they will do this.  Therefore, there is
    no basis for interoperation between objects in environments provided
    by different vendors, nor between heterogeneous brokers.

    DCE in contrast, has completely specified the means of interoperation,
    has in most cases been implemented from the same code base across
    multiple vendors and has had several public demonstrations of
    interoperation between many vendor's products.

    Further, DCE addresses not only the basic problem of handling requests
    and responses, but other important distributed systems problems, such
    as specifying and controlling concurrent execution, providing
    authentication and access control for security and providing
    consistent network time services.  None of these are a part of CORBA
    1.1.

    Even where DCE is missing features essential to significant numbers of
    distributed applications, the means of providing them is well
    understood, and in some cases available today in products which build
    upon DCE.  For example, consider distributed transactions.  The means
    of providing them via RPC has been known for years and transaction
    monitors such as Encina, CICS/6000, ACMSxp and Tuxedo operate or will
    soon operate over DCE.  In contrast, there is as yet no consensus as
    to how to provide distributed transactions in an object environment.

    In summary, at the present time, CORBA-compliant products provide for
    the development of distributed applications only in homogeneous
    environments and lack many of the capabilities essential to
    industrial-strength applications.  In contrast, DCE provides proven
    heterogeneous interoperability and most of the capabilities required
    by robust, production applications.  Additional capabilities can be
    obtained by means of third products built upon DCE.

  Future - Most authorities agree that in the long term object
    technology will be the basis for building large scale distributed
    systems.  In addition to the principle of encapsulation, object-based
    systems allow systems to be built up, evolve and be reconfigured as
    needed because of their ability to dynamically bind requesters to
    objects that provide services.

    There are many specific issues concerning the properties of
    distributed object systems that are the subject of research and
    debate.  It is also clear that there are some features of existing
    local object environments and languages that will not scale
    effectively to large scale distributed systems -- dynamic inheritance
    is one. Never the less, the general direction of the future is clear.

    This is recognized by OSF as well.  Not only has OSF based the DME
    management model on object principles and committed to use the CORBA
    as the underlying implementation tool, but also they have sought to
    add more object oriented features to DCE and research the use of DCE
    technologies as a basis for CORBA interoperability.  After some years
    of remaining at arms length, OSF and OMG are now both members of each
    other.  Individuals and companies associated with both are taking
    active roles in working groups of the other.

    The OMG is now in the process of adding some of the missing pieces of
    CORBA 1.1 by defining CORBA 2.0.  The first subject to be tackled is
    interoperability.  A number of submissions are expected and although
    there are still plenty of differences of opinion, it seems clear that
    DCE will be at least one of the standard ways of providing
    interoperability, perhaps even the most common.

    OMG has taken a leaf out of OSF's book in at least one respect.  Where
    CORBA 1.0 and 1.1 were "paper" specifications, submissions to CORBA
    2.0 are required to refer to working code.  Some of the submissions
    will be publicly demonstrated as soon as this summer (1994) and OMG is
    expected to come to closure on the specification by the end of the
    year.

    OMG has issued requests for technology in several other areas as well.
    Some, such as security and time services are addressed by DCE.
    Others, such as lifecycle (creation and deletion) and persistence
    (database) are not.  Ultimately, it is to be hoped there will be a
    number of CORBA-compliant products to choose from which interoperate,
    provide application portability, offer all the features of DCE and
    more, as well as the benefits of object-based systems.

    Does this mean that it is a mistake to build distributed systems today
    using DCE?  The answer is no for several reasons.  First, many
    organizations cannot afford to do nothing for several years.  End
    users have pressing needs for robust, scalable systems today.  For
    software vendors, waiting would mean attempting to catch up with
    competitors who will have a tremendous head start.

    Second, as this brief discussion has shown, it is possible to employ
    object techniques when developing distributed applications using DCE.
    Carefully designed systems will be able to take advantage DCE features
    such as dynamic binding and polymorphism and converge with
    CORBA-compliant systems as they mature.

    Third, if object environments are to be successful in supporting
    industrial- strength distributed systems, they will have to address
    the problems that DCE addresses.  The skills and techniques developed
    in working with DCE will be directly applicable to distributed systems
    environments of the future.  This applies not only software
    developers, but also to operations personnel, planners, even business
    managers.

    Further, the likelihood that DCE will be a common base technology for
    CORBA interoperability, implies that the eventually migration of
    applications which use DCE directly to an object environment should
    not present any insurmountable difficulties.

    Finally, your direct experience in developing and operating robust
    distributed systems will provide you with great insight into the
    important characteristics of distributed systems environments as they
    apply to your organization's applications.  This knowledge is vital to
    the shaping of successful tools of the future.  History has shown that
    vendors and standards bodies, left to their own devices, will often
    miss the mark.

==================================================================
Q 27: Is DCE IDL the same as all the other IDL's in the world?

    No.

    IDL stands for "Interface Definition Language," and the idea
    of using a special language to define the interface between
    entities is not unique to DCE.  In particular, CORBA's IDL
    is used for the same purpose as DCE's, but the two languages
    are not identical; see Q26 for more information.  There are
    other Interface Definition Languages as well.
    IDL also stands for "Interactive Data Language", which
    is a completely unrelated product.

    When asking or answering a question about IDL, one should be
    careful about specifying which IDL is involved.

==================================================================
Q 28: Can I move idl-compiled stubs from one platform to another and rebuild
      the object files locally?

    No.  You must run the IDL compiler separately on each platform.

    The IDL compiler builds the client and server stubs to handle
    network communication and data marshalling, which are platform-
    specific activities.  Therefore the stub code is not portable
    and must be re-created on each platform.  Likewise, while the
    task of the stub does not change, the set of service routines
    called from the stub may be changed by the vendor for any given
    platform.  Therefore stubs for the same RPC may look very different
    on different platforms.

==================================================================
Q 29: Does DCE Security interoperate with other Kerberos systems?

  Basically, no, or maybe yes, depending on what you want to do.

  To use authenticated DCE services, you must have credentials from
  the DCE security service; vanilla Kerberos v5 tickets aren't sufficient.
  But then, to use DCE services you must be using DCE RPC, so this
  is not really a problem.

  Going the other way, it is expected that a DCE security server
  can issue tickets that can be used by vanilla Kerberos applications.
  The OSF was wary of promising this until the Kerberos v5 specs were
  published, but now that the Kerberos RFC has been published, OSF
  anticipates guaranteeing interoperability sometime "soon".

  In a little more detail, the way to think about this is as follows:

        Kerberos offers 2 services (Authentication Service, Ticket
        Granting Service) over 1 communication mechanism (UDP port 88).

        DCE security offers 3 services (AS, TGS, Privilege Service) over
        2 communication mechanisms (UDP port 88, RPC).

        Where Kerberos and DCE security intersect (AS, TGS over UDP port
        88), the services are identical.

==================================================================

Q 30: Can I use DCE from C++?

   Yes.  First of all, since you can call C functions from C++
   you can access all the DCE services from a C++ program.  But
   that will not give you the benefits of C++.

   There are several packages that provide a C++ interface to DCE.
   They different quite a bit in style and approach, so you'll
   need to consider them carefully in light of your own needs and
   preferences.

   Objtran was produced by Citibank, and is available by anonymous
   ftp at ftp://wilma.cs.brown.edu/pub/Objtran.tar.Z

   HaL Computer Systems has a system called DCE++.  It is available
   for free, but requires a license agreement.  For more information
   retrieve the file ftp://ftp.hal.com/dce++/license, or
   send email to [e-mail]

   Hewlett-Packard has a product called OODCE.  It is for sale,
   and currently supported only on HP-UX.  For technical information
   retrieve the OSF RFC #49 (see Q33);  for sales information
   contact your HP sales office.

==================================================================

Q 31: Can I write an application that uses DCE and X11/Motif?

  Yes but there are several serious pitfalls.

  The X11/Xt/Motif libraries may not be thread-safe.  For example,
  suppose one thread calls a function in Xt, which calls a nonthreadsafe
  malloc(), which then gets preempted.  The next thread may call
  a threadsafe malloc() that comes with DCE. When control returns to
  the first malloc(), any assumptions about the state of the heap are
  invalid.

  Also, Motif/Xt/Xlib are not currently reentrant wrt/themselves.  You can't
  have multiple threads concurrently manipulating any Motif/Xt/Xlib
  global state. Fortunately this issue is under you control when
  designing the application.  X11R6 includes a thread-safe version of
  Xlib, but it will be a while yet before the vendors are all delivering
  thread-safe Motif.

  A related issue is that XtAppMainLoop() waits in a select() for activity,
  coupled with the fact that DCE also waits in a select() for activity.
  Unless the two are select()s are cooperating, one or the other will be
  starved. This is a platform-specific issue, you should check with your
  DCE vendor for full details.
  If it is a problem in your environment, the standard solution is to
  encapsulate the GUI in one process, the DCE client code in another process,
  and connect them with a simple IPC such as a Unix pipe.

==================================================================
Q 32: Where can I get more information about DCE and DCE-related products?

  With WWW, access the URL: "http://www.osf.org:8001/dce/index.html"

  The general response to any query of the form "Where can I get a _____ for
  DCE?" is "Contact [e-mail]" (phone [phone]).

    This mail list will reach the people at OSF that maintain contacts with
    just about everbody that has a DCE product to sell.  You can get a listing
    of the vendors and their products.  These include DCE RPC debugging
    environments, C++ toolkits, Visual-BASIC  development environments, etc.

    This mail list also reaches the people at OSF that maintain the lists of
    documentation available, both from OSF, and from outside OSF, about DCE
    (and about Motif, DME, and OSF/1).

  Transarc maintains a mail alias,ROT:    PLURIBUS.wupper.de!mechti!wupper.de!gomel.knirsch.de!Dortmund.Germany.EU.net!Germany.EU.net!howland.reston.ans.net!news.sprintlink.net!redstone.interpath.net!tophat
ABS:    [e-mail] (Jon Mauney)
BET:    OSF Distributed Computing Environment Frequently-asked questions
ERSETZT:    [e-mail]
DISKUSSION-IN:    /COMP/SOFT-SYS/DCE
EDA:    19950218032353W+0
U-Date:    18 Feb 1995 03:23:53 GMT
ORG:    Mauney Computer Consulting
U-Lines:    1037
U-Approved:    [e-mail]
U-Distribution:    world
U-Expires:    24 Mar 95 23:22:39 EDT
MID:    [e-mail]
ANTWORT-AN:    [e-mail] (Jon Mauney)
U-NNTP-Posting-Host:    jtec.mauney.com
U-Summary:    Answers to frequently asked questions aboutthe Open Software Foundation's Distributed Computing Environment (DCE).It provides a brief overview of what DCE is, pointers to sources ofmore information on DCE, and answers to common technical questions.
U-Keywords:    DCE Distributed Computing FAQ
U-Originator:    mauney@tophat
LEN:    50546
EMP:    /COMP/SOFT-SYS/DCE
EMP:    /COMP/ANSWERS
EMP:    /NEWS/ANSWERS
GATE:    RFC1036/822 PL PLURIBUS.wupper.de [Connectline/AmigaOS]

Posted-By: auto-faq 3.1.1.2
Archive-name: dce/faq
Revision: 1.6 1995/02/18 03:00:59
Posting-frequency: monthly



  This document answers some Frequently Asked Questions concerning
  the OSF Distributed Computing Environment.
  It is posted monthly to comp.soft-sys.dce, as well as
  comp.answers, and news.answers.

  The document is maintained by Jon Mauney, [e-mail]
  Suggestions, corrections, and updates are actively sought.

  This FAQ is available by anonymous ftp from
        ftp.dstc.edu.au in /pub/DCE/FAQ
  and is available for browsing at the OSF's WWW server.
        http://www.osf.org:8001/dce/faq-mauney.html

  Last modified on Feb 14, 1995

Questions answered in this document:

Q 1: What is DCE?
Q 2: What are the advantages of DCE?
Q 3: Where can I get online information about DCE?
Q 4: What books are published on DCE?
Q 5: What about books on DME?
Q 6: What platforms support DCE?
Q 7: What products use DCE?
Q 8: Several of the other questions concern "interfaces".
      What is meant by an interface in DCE RPC?
Q 9: Can a DCE client import multiple interfaces?
Q 10: Can a DCE client connect to multiple servers?
Q 11: Can a DCE server export multiple interfaces?
Q 12: Can a process be both a server and a client?
Q 13: How do I perform asynchronous RPC?
Q 14: How can a server keep track of multiple clients?
Q 15: How can a server detect that a client as exited or crashed?
Q 16: Will Windows NT communicate with DCE?
Q 17: How efficient is DCE RPC?
Q 18: What is the practical limit on the size of a DCE cell?
Q 19: How much memory and disk space is required for DCE services?
Q 20: Where can I find an ACL manager to include in my application?
Q 21: Is DCE an official standard?
Q 22: The DCE threads uses draft 4 of the standard, but
  Posix threads standard has moved beyond draft 4.
  Will DCE change to the most recent standard?
Q 23: Is anyone using DCE for real-life mission-critical systems?
Q 24: Is it possible for a machine to be a member of more than one DCE cell?
Q 25: Is it possible for a user in one cell to use secure services
  in another cell?
Q 26: What is the relationship between DCE and CORBA?
Q 27: Is DCE IDL the same as all the other IDL's in the world?
Q 28: Can I move idl-compiled stubs from one platform to another and rebuild
      the object files locally?
Q 29: Does DCE Security interoperate with other Kerberos systems?
Q 30: Can I use DCE from C++?
Q 31: Can I write an application that uses DCE and X11/Motif?
Q 32: Where can I get more information about DCE and DCE-related products?
Q 33: What are DCE RFCs, and how can I get them?
Q 34: Where can I get the Public Domain version of DCE?
Q 35: Is there a DCE Users Group I can join?

==================================================================

Q 1: What is DCE?

   DCE is the Distributed Computing Environment, from the
   Open Software Foundation. (It is called "the DCE" by sticklers
   for grammatical consistency.)

   DCE consists of multiple components which have been integrated
   to work closely together.  They are the Remote Procedure Call
   (RPC), the Cell and Global Directory Services (CDS and GDS), the
   Security Service, DCE Threads, Distributed Time Service
   (DTS),and Distributed File Service (DFS).  The Threads, RPC, CDS,
   Security, and DTS components are commonly referred to as the
   "secure core" and are the required components of any DCE installation.
   DFS is an optional component.  DCE also includes administration tools
   to manage these components.

   DCE is called "middleware" or "enabling technology."  It is not
   intended to exist alone, but instead should be bundled into a
   vendor's operating system offering, or integrated in by a third-party
   vendor.  DCE's security and distributed filesystem, for example,
   can completely replace their current, non-network, analogs.
   DCE is not an application in itself, but is used to build custom
   applications or to support purchased applications.

==================================================================
Q 2: What are the advantages of DCE?

   First, DCE provides services that can be found in other computer
   networking environments, but packages them so as to make them
   much easier to use.  For example, the DCE Remote Procedure Call
   (RPC) facility provides a way of communicating between software
   modules running on different systems that is much simpler to code
   than older methods, such as using socket calls.

   Second, DCE provides new capabilities that go beyond what was
   available previously. The DCE Security Service provides a
   reliable way of determining if a user of a distributed system
   should be allowed to perform a certain action, for example.  This
   is very useful for most distributed appli